Containers, as driven by the popularity of solutions such as the Docker™ software containerization platform provided by Docker, Inc., have recently emerged as a lightweight alternative to hypervisor-based virtualization. Containers are essentially just processes that enjoy virtualization of all resources, not just CPU and memory; as such, there is no intrinsic reason starting a container should be more costly than starting a regular process.
Unfortunately, starting containers is much slower in practice due to file-system provisioning bottlenecks. Whereas initialization of network, compute, and memory resources is relatively fast and simple (e.g., zeroing memory pages), a containerized application requires a fully initialized file system, containing application binaries, a complete Linux distribution, and package dependencies. Deploying a container in a Docker™ or Google Borg™ cluster typically involves copying packages over the network, unpacking these to a local directory, and using that directory as the root file system for the new container. Median container startup latency has been seen to be 25 seconds in a recent Google Borg™ study.
If startup time can be improved, a number of opportunities arise: applications can scale instantly to handle flash-crowd events, cluster schedulers can frequently rebalance nodes at low cost, software upgrades can be rapidly deployed when a security flaw or critical bug is fixed, and developers can interactively build and test distributed applications.